Skip to content

Replace decimal year conversions with julian year conversions. - #382

Open
sblunt wants to merge 19 commits into
mainfrom
decimalyear-to-julianyear
Open

Replace decimal year conversions with julian year conversions.#382
sblunt wants to merge 19 commits into
mainfrom
decimalyear-to-julianyear

Conversation

@sblunt

@sblunt sblunt commented Oct 8, 2024

Copy link
Copy Markdown
Owner

See issue #372. This doesn't have any big impact on the Hipparcos IAD refitting, but maybe it affects things on longer timescales (i.e. hipparcos-gaia). Will continue to investigate.

@sblunt
sblunt requested a review from semaphoreP October 8, 2024 21:37

@semaphoreP semaphoreP left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it generally looks good to me. Did you have a chance to run an HGCA orbit fit to see if it matches previous results?

Comment thread orbitize/hipparcos.py Outdated
sblunt and others added 14 commits July 28, 2026 13:15
Actually use pool in ptemcee
periodic_save_freq previously re-derived the entire chain history (including
an unvectorized per-sample prior recomputation) and rewrote the whole HDF5
output file on every periodic save, making cost grow with total run length
instead of just the new chunk. _update_chains_from_sampler now only
processes steps since the last save, and Results.save_results appends to
resizable HDF5 datasets instead of rewriting the file each time.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… saves

Results.add_samples() used np.vstack/np.append, which reallocate and copy
the entire accumulated post/lnlike arrays on every call. This meant that
even after the earlier fix to periodic_save_freq (only recomputing/writing
new chunks), the in-memory accumulation itself was still O(total rows so
far) per periodic save, making the MCMC fit progressively slower as it ran.

add_samples now writes into a capacity-doubling internal buffer, so appends
are amortized O(1) per row instead of O(n) per call.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants